[WIP] Span name provider #5
Conversation
In current implementation the generated operation name corresponds to the request's http method e.g. GET, POST etc. It's not perfect when you look at UI and want to quickly understand what was called. You need to dig into the trace to understand with what url it's related. This change introduces a capability to specify a custom span name provider, and defaults to http method and host of the url.
iaintshine
force-pushed
the
span-name-provider
branch
from
ede0849 to
ac17e4d
Compare
|
There are some docs about the operation name here https://github.com/opentracing/specification/blob/master/specification.md#tracer I've looked some other libraries as well. Most of them have just the http method. There are few exceptions. I do agree that just the method name doesn't provide much information. The PR looks ok, but I'm even thinking that maybe the more detailed name should replace the legacy one. @bhs Do you have any recommendations here? |
|
Potentially for backwards compatibility we could leave the |
|
Maybe the better idea would be to introduce decorators, as it was done in java e.g. https://github.com/opentracing-contrib/java-jaxrs/blob/master/opentracing-jaxrs2/src/main/java/io/opentracing/contrib/jaxrs2/client/ClientSpanDecorator.java. The implementation includes a decorator for http path operation name see https://github.com/opentracing-contrib/java-jaxrs/blob/master/opentracing-jaxrs2/src/main/java/io/opentracing/contrib/jaxrs2/client/ClientSpanDecorator.java#L60. Decorators allow for composition, and custom logic. You would be able to inject custom code during request, response, and on error, decorate current span, set custom operation name, add custom tags, logs etc. Wdyt ? |
|
FYI: opentracing-contrib/meta#25 (Meaningful operation names when using framework integrations) |
|
@mabn thanks for the reference. I agree with the following comment:
this is what i meant in the last comment, and suggest to implement the abstraction using decorators, as it was done in Java. The default/standard decorator might generate operation name in the current form for backwards compatibility. |
|
Closing the PR, as I'm willing to go with decorators approach |
In current implementation the generated operation name corresponds to the request's http method e.g. GET, POST etc. It's not perfect when you look at UI (I use Jaeger) and want to quickly understand what was called. You need to dig into the trace to understand with what url it's
related.
This change introduces a capability to specify a custom span name provider, and defaults to http method plus host of the url.
@indrekj I still need to add documentation and tests, but wanted to verify the concept and if you think that might be useful to others.